ss13flotillafandomcom-20200215-history
Mechanics
This page details the mathematics and ideas behind the mechanics of the game. Physics The backbone on which the Flotilla idea is built, physics simulation is an important aspect of an interesting space game. We've chosen to base the physics for the game off of newtonian motion with some nods to relativity; specifically by making acceleration decrease with velocity and properly respecting the higher momentum of objects traveling at relativistic speeds. *Physics will be done in 3D space *Gravitation is calculated using the Barnes-Hut approximation of gravitation *Positioning is tracked on a cartesian co-ordinate system using double precision floating point numbers. **Based on the barycentre of the local star system. ***Need to figure out how to manage movement between stars. E.g. you fly from one star to the next, what happens at the halfway point? **Velocity and Acceleration are tracked, and used to compute the next location of the vessel. ***Acceleration is based off of the direction the ship is facing, to make it easier to code engines and maneuvering thrusters. *Collision detection is handled each tick for each leaf of the octtree, thus allowing efficient collision detection without having to compare each object to every other object. Simulating Physics Each in-game second, the game computes the next positon and velocity of all objects in the simulation. The general order of operations is as follows: Determine gravitational effects, determine the next velocity and position of all objects, determine if any collisions are to occur, simulate collisions, update the locations and velocities of all objects. *Gravitational changes to velocity are calculated. **This directly modifies the velocity, bypassing the acceleration variable, since that is used for applied thrust. *The velocity is adjusted by the acceleration. *The velocity and current position are used to compute the new position in the octtree, in case the object has moved enough to change nodes/overflow into another node *Collision detection is preformed **Each object in each node is compared to other objects in the same node. **Initially a two rectangular prisms are computed, representing the greater volume of space which the two objects have moved through. ***If these rectangles do NOT overlap, there is no way the objects could colide this tick, so continue on to the next comparison. **From there, compute the time at which the objects make contact. ***If the time is either non-existant, or is outside the timeframe being simulated (e.g. if they would contact in 1.5 seconds, and we are only advancing time by 1 second) continue on to the next check. **The two objects DO contact, so calculate precisely when they hit, at what angles, what force, etc. Apply these effects, adjust their velocities to ones that make sense based on the collision. *Adjust the positions of the objects based on their velocity, in a single linear step since lol-close-enuff *Wait for the next tick to come along Requirements, Code Wise *Oct-tree capable of handling objects in multiple nodes at a time. Will likely be coded from scratch. To Be Determined *Shape of data type that represents a frame of reference. e.g. a ship, station, etc. **Currently working on the assumption of a spherical one for massive bodies (moons, planets, stars) and rectangular prism for smaller objects, fully containing the map of the object. **e.g. A ship 100m long, 30 meters wide, and 20 meters tall would have a frame of very-slightly larger size than that. *Mathematics for efficiently and accurately computing the time and point of collision between combinations of rectangular prisms and spheres. **The sphere and sphere combo is solved already. *How to represent asteroid fields and ring systems. Obviously not simulating every object. **Currently operating on the idea of a density field that has some variables governing it changing with time. e.g. having an asteroid orbit the star even when no ships are around it and it is not being explicitly simulated. *Mechanics of signalling between ships Materials To expand upon the ChemAtmos concept of yesteryear, the current idea is to Mechanics Mechanics Computers and Networking In SS13 the computers are massive doo-dads that are essentially a display with usually no more than a few buttons. They operate by majiks, and are very very limited. What I would much prefer to see is the computers of SS13 replaced with thin terminals linked (via network cabling) to a central mainframe which runs the ship, with the machinery that is normally controlled connected by either a futuristic wireless network, or by a direct link with a networking cable. This would produce two major changes: *Machinery would no longer be controlled by majick handwavium from the terminals they are code-wise linked to (and thus are impossible to fix in-game) and would instead be accessible from the network by any computer that sends properly formatted commands with the right authorization **e.g. Someone loads the operative program onto their PDA (or equivalent) so that they can login to the program with their credentials, and then have the exact same capabilities from their PDA as they would have standing in front of the standard terminal. *Network Maintenance and Hacking - Since the network is an actual thing that devices use to talk to each other, it needs to be maintained and can be used for not-quite-legal activities. Other possible effects: *The PDA is used for more than just messaging people and checking the crew manifest *Replacement of the normal radio channels with essentially a teamspeak for departments. *Bulletin boards that the crew members can access. *Inter-ship communications? *Subnets? e.g. have the engineering equipment on a subnet as to prevent someone hacking in and fucking shit up easily. Structure of the Network In general, I will be basing the structure of the in-game networking off of real-life networking principles. Routers will be installed throughout the ship, to provide connectivity both mobile devices (PDAs and technical equipment) and stationary units that do not require enough throughput to justify a phsyical connection (maybe doors, fire alarms). (Military ships and whatnot may completely forgo wireless transmissions of data due to security issues.) Physical connections would be of the form of a wire, based off the same code as a the power cables, and would be fluffed as being able to be spliced easily and without issue. (However, this may change in the future as this is just a suggestion.) Cabling Ideas: #Identical to the current system in SS13, cabling would be done tile-by-tile. #Differing from the current system in that cable is laid in a single piece, and then is cut and terminated once it is all laid. This has the advantage of allowing an engineer to place the start of a cable, and then simply walk to the destination, using a cutting-thing on the cable and terminating it. In addition, there should be the capability to produce and utilize a cable that has both power and network cables attached to one another, laying both at once, and splitting them into separate lines when needed. Signalling on the Network Possibilities: *The network is treated like a powernet, with a packet being placed in it, sniffers would detect it, then the target computers (if any) would receive it and it would disappear. *The network incorporates actual packet routing, and sniffing would either need to be done via a router or by splicing into a cable you know is between the two relevant parties. **More complex, but also more interesting from a gameplay perspective. Would require routers and the like to have routing tables, which should not be player-modifiable due to the possibility of infinitely looping packets and crap. Networked Devices All objects connected to the network must have an operating system (more on that later) and a means for the operating system to talk to the network in both directions. Operating Systems There are two types: #Full OS - This is what you would have on a PDA or a Terminal. #Embedded OS - For devices such as a air scrubber or a door, it has no interface except for network commands. No matter which type it is, an operating system must have the following information: *A MAC address - Unique address that is assigned by the hardware. Can be spoofed by software or hardware modification. *An IP address - Assigned by the ship's mainframe, this address is used for most communication. *A device identifier - A string which acts as the devices name. In addition, the device will need a network card for either a physical or a wireless connection to be made. (e.g. a fibre-optic interface card or a wireless card) Packets The actual means by which data is transferred between devices on the network. Will either be a Object that contains the routing information or a Vector that contains strings of the same info. Structure of a fibre-optic packet: *Address of destination **MAC address is used if the mainframe is down, and can only travel to the directly connected devices **IP address will be routed to the destination if it exists. *Address of sender **MAC address if mainframe is down, otherwise IP *Command - String of the sent command *Subsequent entries in the Vector are arguments to the command. An example packet would be "192.168.2.145 192.168.1.107 ping" which means to send the command "ping" to "192.168.2.145", from the computer at "192.168.1.107" "192.168.1.1 192.168.2.232 shutdown rzhalimit a9yh3b20fjl8208jd" would be an example command telling "192.168.1.1" (Likely the mainframe) to shutdown, with authentication by "rzhalimit" and the user's password. Mechanics Mechanics